境界づけられたコンテキストは、ドメイン駆動設計の中心的なパターンです。これは、大規模なモデルとチームの扱いを扱うDDDの戦略的設計セクションの焦点です。DDDは、大規模なモデルを異なる境界づけられたコンテキストに分割し、それらの相互関係を明確にすることで、大規模なモデルを扱います。

アジャイル手法に関してよくある誤解があります。それは、ユーザーストーリーの作成方法と開発活動全体への流れ方に関するものです。この誤解は、プロダクトオーナー（またはビジネスアナリスト）がユーザーストーリーを作成し、開発者に実装を依頼するというものです。これはプロダクトオーナーから開発への流れであり、プロダクトオーナーは*何を*行う必要があるかを決定し、開発者は*どのように*行うかを決定するという考えです。

一流のエンタープライズソフトウェア開発者を構成する要素について議論する場合、フレームワークや言語の知識、あるいは複雑なアルゴリズムやデータ構造を理解する能力についての話になることがよくあります。私にとって、プログラマー、あるいは開発チームにおいて最も重要な特性の1つは、顧客との親和性と呼ぶものです。これは、開発者がソフトウェアが対処するビジネス上の問題、そしてそのビジネスの世界に住む人々に対して持つ興味と親密さです。

ストーリーがプロダクトオーナーまたはアナリストによって書かれ、開発者に渡されて構築されるアプローチ。私はこれをアジャイル思考の根本的な誤解と見なしているため、会話型ストーリーを強く推奨します。

アジャイル手法の一般的な、おそらく支配的なプラクティスは、構築中のソフトウェアの機能のリスト（多くの場合、ストーリーと呼ばれる）を作成することです。これらの機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログ、または選択したツールで追跡されます。

多くの企業は、スコープと価格を固定する契約を結ぶことを好みます。なぜなら、それがリスクを軽減すると考えているからです。この幻想は、彼らの財政的義務が取引価格で固定されていると述べています。満足のいくソフトウェアを入手できなくても、費用はかかりません。

歴史は大体無駄である

-- ヘンリー・フォード

最近、UML Distilledの読者から不快なメールを受け取りました。怒っている読者が私の言葉を時折賢明な言葉として買うことを後悔し、ましてや読むことを後悔するのは、私にとって良い一日が始まることはありません.しかし、この読者の牛肉には特に興味深いものがありました.彼の具体的な不満は、私の「不必要な歴史」についてでした.

要件とは、製品の構築を開始する前に発見すべきことです。建設中、あるいはさらに悪いことに、クライアントが製品を使い始めたときに要件を発見することは、非常に費用がかかり、非効率的であるため、正気の人なら誰もそんなことはしないと仮定し、二度と言及しません.

-- スザンヌとジェームズ・ロバートソン

アジャイル手法は、構築中および配信後に「要件」を発見することを意図することにより、この基本的な仮定に違反しています。しかし、上記の賢明なアドバイスをこのように軽視することさえ、今日多くの主要なWebサイトが行っていることと比較すれば何でもありません.これらのサイトは、ユーザーがサイト上で行うことを観察し、その情報を使用して、次のような新しい機能のアイデアを生成することにより、要件を探ります.

オンサイト顧客は、ホワイトブックに記載されている12のプラクティスの1つである、エクストリームプログラミングのプラクティスの1つです。顧客は、質問に答え、開発チームと対話するために、オープンな作業エリアで開発者と一緒に座る必要があると述べています。実際、彼らは開発チームの一員であり、チームの成功は開発者と同じくらい彼らにかかっていることを認識しています。彼らはこれを行うために通常の仕事を諦める必要はありませんが、物理的に存在している必要があります.

アジャイル開発の重要な特性は、機能の小さなサブセットでシステムを稼働させる方法を見つけることです。私たちはビジネス価値を提供するためにソフトウェアを構築します。稼働が早ければ早いほど、少なくともそのビジネス価値の一部を早く得ることができます.

アジャイル開発の基本原則の1つは、要件の変更が単に予想されるだけでなく、歓迎されるということです。これは、Thoughtworksのような外部企業がクライアントのために仕事をしている場合に、特に課題となります。多くのクライアントは、固定スコープの幻想を見ているため、固定価格の取り決めを望んでいます。しかし、固定スコープ契約はアジャイル開発とは全く相容れないため、私たちのような企業はどうすればよいでしょうか？

2002年にXP/Agile Universeのワークショップに参加していたとき、「例による仕様」という言葉が、XPにおけるテストの役割の1つを説明する方法として頭に浮かびました.

最近、エクストリームプログラミングの計画アプローチを使用している複数のチームのための標準的なストーリーポイントメカニズムの作成について、いくつかの質問を耳にしました。目標は、複数のチームすべてが同等のストーリーポイントを使用するようにすることです。そのため、あるチームの3つのストーリーポイントの労力は、別のチームの3つのストーリーポイントの労力と同じになります.

これはせいぜい価値が限られており、最悪の場合は危険だと考えています.

モバイルアプリケーションは、過去数年間、ソフトウェア開発のホットなアイテムとなっています。多くのソフトウェア配信会社と同様に、Thoughtworksはクライアントからモバイルアプリケーションの構築を依頼されることがよくあります。しかし、ほとんどの場合、企業が私たち（または誰か）にモバイルアプリケーションの構築を依頼するとき、彼らは間違ったスタートを切っています。ほとんどの場合、ユーザーにモバイルデバイスと対話してもらいたい場合でも、**モバイルアプリケーションの構築を決して考えてはならない**と主張します。代わりに、モバイル、デスクトップ、タブレットなど、ユーザーが使用する可能性のあるあらゆるデバイスで表示される単一のアプリケーションの構築について考える必要があります.

ユースケースは、要件を整理し、引き出すための手法です。これらは、元々1980年代後半から1990年代初頭にイヴァー・ヤコブソンによって普及しました.

ユースケースとXPのユーザーストーリーの違いは何ですか？

ユーザーストーリーは、ソフトウェアシステムの望ましい動作の塊です。これらは、アジャイルソフトウェアアプローチで広く使用されており、計画のために大量の機能を小さな部分に分割します。同じ概念を**機能**と呼ぶこともありますが、「ストーリー」または「ユーザーストーリー」という用語は、最近のアジャイルの分野では一般的になっています.